Connectionless packet networks using the Internet Protocol (IP) are well established. Connection oriented Multiprotocol Label Switching (MPLS) packet networks have been developed for IP packet networks, using Label Switched Routers (LSRs) instead of IP routers for traffic engineering.
FIG. 1 illustrates the concept of an MPLS packet network 10 according to the prior art. Though the concept is illustrated with IP network connectivity, the application is not limited to IP networks only. The MPLS packet network 10 provides connectivity between a first IP network 12 and a second IP network 14. The first IP network 12 is connected to a first Label Edge Router (LER) 16 over link 18. The second IP network 14 is connected to a second Label Edge Router 20 over link 22. Inside the MPLS packet network 10, LER 16 and LER 20 are connected to one or more Label Switched Routers (LSR) 24 over links 26 and 28 respectively. Typically, a number of LSRs are configured in the network 10 to provide the desired connectivity, the dashed line 28 indicating the possibility that there may be several LSRs in the route between LER 16 and LER 20.
A Label Switched Path (LSP) 30 is shown to extend from LER 16 to LER 20 through the LSR 24, an LSP indicating a route followed by a particular stream of packets through the MPLS packet network.
In operation, LSPs 30 between the LERs 16 and 20 of a MPLS packet network 10 are established during a signalling phase using, e.g., the RSVP-TE protocol described in Internet Engineering Task Force (ietf) document RFC 3209. By way of example, LSP 30 might be established for the purpose of providing a connection between IP network 12 and IP network 14. During the data transfer phase, IP packets originating in IP network 12 and destined for IP network 14, enter the MPLS packet network at LER 16 in the form of regular IP packets. Then the IP packets are encapsulated in MPLS packets in the LER 16 to flow through the MPLS packet network 10 following the LSP 30 that was established, and then the MPLS packets are de-capsulated back to regular IP packets in LER 20 and sent to IP network 14 over link 22.
An MPLS router (an LSR 24) forwards packets on the basis of an MPLS label, which logically defines a label switched path (LSP) through the network. Packets with different IP addresses may frequently need to be switched through the MPLS packet network over the same path. For example, all packets from the IP network 12 to the IP network 14 in FIG. 1 may follow the same path even though they originate from different computers in IP network 12 and are destined for a number of different computers in the IP network 14.
The efficiency of the MPLS packet network 10 derives from the fact that the individual LSRs 24 along the path only need to inspect the MPLS label of each packet to route it, instead of decoding the IP address.
Accordingly, the MPLS packet network 10 is said to be connection oriented, because for each packet stream to traverse the network, a connection, that is a label switched path, must exist and have been set up by a connection establishing protocol.
In FIG. 2 is illustrated a MPLS packet network providing two distinct LSPs to carry different classes of traffic, according to the prior art. FIG. 2 is a more detailed view of the network shown in FIG. 1.
In addition to the first LSR 24, the MPLS packet network 10 contains exemplary second and third LSRs (reference numbers 40 and 42 respectively).
Two connections are shown, linking computers in the first and second IP networks, and representing two classes of service (COS1 and COS2). A first connection 44, shown in a dotted line, extends from a computer 46 in the first IP network 12 to a computer 48 in the second IP network 14. The connection 44 comprises segments from the computer 46 to the first LER 16 over link 18; from the LER 16 over link 26 to the first LSR 24; from the LSR 24 to the second LER 20 over link 28; and finally from the LER 20 to the computer 48 over link 22.
The path, represented by connection 44, is taken by COS1 packets sent from computer 46 to the computer 48. It contains IP segments on links 18 and 22 at the edge of the MPLS packet network, and a MPLS label switched path (LSP) 50 which extends from the first LER 16 to the second LER 20 within the MPLS packet network.
A second connection 52, shown in a heavy solid line, extends from a computer 54 in the first IP network 12 to a computer 56 in the second IP network 14. The connection 52 is similar to connection 44 but uses a different label switched path (LSP) 58 within the MPLS packet network, and carries COS2 packets.
Different IP networks may be owned or operated by different organisations, such as ISPs (Internet Service Providers), or may be components of private networks. MPLS packet networks, on the other hand, may be owned or operated by yet other organisations. As such, MPLS packet networks provide the capability to establish paths between specific IP or other Layer 2 networks at their edges, including the ability to connect several geographically distributed parts of a private network together.
Another concern with packet networks is the Quality of Service (QoS), including delay, bandwidth availability, and packet loss.
The current service model in the Internet is Best-Effort. In this framework, packets are routed using a shortest path algorithm, and there is no differentiation accorded to user packets in the router Forwarding Plane (FP). The emergence of the Internet as an inter-communication network with global reach has led to renewed efforts to develop service models that can guarantee or assure a certain quality of service for end users.
The technologies for addressing QoS in packet networks differ depending on the packet protocol of interest at the present time is primarily the provision of differentiated QoS in both IP and MPLS packet networks.
Traffic Engineering (TE), see e.g., Awduche et al, “Requirements for Traffic Engineering Over MPLS”, ietf RFC 2702, September 1999, is one of the key elements in the tool-kit to deliver some level of guaranteed service (in the form of Service Level Agreements) to the end-users. Initial TE solutions used MPLS to steer best-effort traffic away from shortest-path congested links. Such an approach improves network utilization and enhances performance for best-effort traffic.
Recent initiatives have resulted in the development of the Diffserv (Differentiated Services) architecture, see Blake S. Et al, “An Architecture for Differentiated Services”, ietf RFC 2475, December 1998, as a means of providing multiple classes of traffic for IP networks. Consequently, there is a desire to extend the current TE mechanisms to MPLS networks to carry multiple classes of traffic. This approach is referred to as DS-TE (Differentiated Services Traffic Engineering).
The currently accepted DS-TE approach allows an MPLS packet network to support multiple classes of traffic, but it has a number of limitations. First, it requires that each MPLS path carry only a single class of traffic (COS). Secondly, the scheme requires manual configuration of additional mapping information at each node in the network. Finally, the scheme imposes undesirable restrictions on the pre-emption relationship amongst various classes-of-service. Pre-emption comes into play when LSPs are setup. An LSP with high set-up priority can supersede a low holding priority connection due to lack of resources. Pre-emption priority is unrelated to the class of service and as such should be treated separately. The solutions discussed in the traffic engineering workgroup (TE-WG) of IETF explicitly state that there is no value in supporting a DS-TE solution that enables multiple classes of traffic to be carried over a single LSP. The current DS-TE solutions assume that the service provider use either L-LSP or E-LSP that carries only a single class of traffic. With Label-only-Inferred-LSPs (L-LSP), the CoS is explicitly signalled at label establishment time so that after the label establishment, the LSR can infer exclusively from the label value the CoS to be applied to a labeled packet. In case of EXP-inferred-LSPs (E-LSP), the CoS of a packet transported on this LSP depends on the EXP field value for that packet.
We will now briefly describe the six key elements, which are required to support a Differentiated Services Traffic Engineered IP network, based on the current approach to DS-TE for a single class of service (COS) as defined in the ietf draft to Le Faucheur et al, cited above. 1. The IGP (Interior Gateway Protocol) routing protocol (e.g Open Shortest Path First, OSPF) advertises per-link, per-preemption-priority allocated bandwidth. There are eight priority levels specified. These levels are historically intended to correspond to pre-emption priority levels of MPLS LSPs. Thus, each OSPF advertisement would flood unreserved bandwidth for each of the 8 priority levels of an interface. The protocol extensions for this method can be found in ietf draft by Katz et al, “Traffic Engineering Extensions to OSPF”, Internet draft<draft-katz-yeung-ospf-traffic-06.txt>, October 2001.
2. At the network edge, the routing device derives the network topology based on received IGP advertisements. When the device receives a request to setup a constraint based LSP to a particular network egress device, it runs a path computation algorithm to find a path that satisfies the necessary constraint. In this case, the path computation algorithm finds a path that can satisfy the bandwidth requirement for a single class of service. At the node, the operator has to configure the computation algorithm to map the OSPF priority levels to a specific class of service. The output of the path computation algorithm is the explicit route (hops along the path) from network ingress to network egress.
3. The network edge device (the LER) then requests an LSP to be setup from itself to the network egress along the explicit route determined in the previous step. The signaling protocol used may be either RSVP-TE described in ietf draft RFC 3209 or CR-LDP described in IETF draft RFC 3212. The current RSVP-TE specification has no way of explicitly specifying the class of traffic for an LSP. Traffic parameters for only a single class of traffic can be signaled as part of the LSP setup.
4. At each node along the explicit path from ingress to egress, Connection Admission Control (CAC) is executed to determine whether or not a request can be admitted. The CAC algorithm maintains the equivalent of buckets for each of the priority levels to determine how much bandwidth has been used and whether or not a new request can be admitted. Periodically, as the bandwidth usage for different levels exceeds certain thresholds, CAC informs the local routing module of a node of this change so that it may advertise these values as part of new LSAs (Link State Advertisements) being sent to the rest of the routers on the network.
5. At each node, the forwarding plane queuing and buffer management parameters can also be dynamically modified based on bandwidth reservation in the control plane. In this way, instead of having to statically restrict the bandwidth used by each class of service, it can adjust automatically based on actual customer demand. This provides for a more manageable network. The forwarding plane queues and buffers are typically configured based on classes of service based on Diffserv PHBs (Per Hop Behaviour). This is done through an operator configured table that maps priority levels to Diffserv PHBs and/or classes.
6. At the network ingress device, the packet classification and policing mechanisms aggregate customer traffic based on specified traffic filters, meter, police and mark the traffic to receive treatment with a Diff-Serv PHB before mapping the traffic to traverse a pre-set LSP. The EXP (explicit) bits of the MPLS label are marked to indicate the PHB treatment for each packet. The label will guide the packet onto the LSP that was set up in previous steps.
LSP Setup
Another component in a DS-TE architecture involves the set-up of the LSP that is used to carry the traffic across the network. Two different types of LSPs can be set-up. Diffserv over MPLS (DS-MPLS), described in ietf draft by Le Faucheur F et al, “MPLS Support of Differentiated Services”, Internet draft, <draft-ietf-mpls-diff-ext-09.txt>, April 2001, defines methods to setup DS-TE LSPs in an MPLS network. Two different types of LSPs can be utilized, these are commonly referred to as E-LSPs (EXP-inferred-LSPs) and L-LSPs (Label-Only-Inferred-LSPs). More details can be found in Rosen, E. et al, “MPLS Label Stack Encoding”, ietf RFC 3032, January 2001 and Blake, S. et al, “An Architecture for Differentiated Services”, ietf RFC 2475, December 1998.
Apart from the type of LSP utilized, there is also the signaling protocol to be considered. In an MPLS network, where the LSP path is determined at the network ingress node, either CR-LDP, see Jamoussi, B. et al, “Constraint-based LSP setup using LDP”, RFC 3212, or RSVP-TE, see Awduche, D. et al, “RSVP-TE: Extensions to RSVP for LSP Tunnels”, RFC 3209, may be used as signalling protocols.
There are a number of examples where the current DS-TE solution is deficient, some of them being listed below.
Voice-Over-IP
With such traffic, it is desirable for the voice data and signaling to be treated as different classes and carried through the network efficiently. The easiest way of doing this is to transport the data and signaling on different classes in a single LSP.
Virtual Private Networks
A key emerging application for E-LSPs with multiple classes is Layer 2 Virtual Private Networks (L2VPN). In this context, service providers (SP) for the Metropolitan Networks seek to provide TLAN (Transparent LAN) services. The SP may provide Layer 2 VPNs for its end customers where the key SLAs (Service Level Agreements) revolve around availability and QoS (Quality of Service). In such cases, the SLA may specify a single protection level for the aggregate while specifying multiple classes of service within the VPN. In such networks, the current DS-TE solution requires that different classes of service are sent on different LSPs which immensely complicates the ability to offer robust and measurable availability and QoS SLAs to such customers.
Path Protection
Path protection and restoration mechanisms are two key requirements in modern packet networks. The current DS-TE solution usually requires a single customer's traffic to be carried over a large number of LSPs in the network. This causes issues with ensuring that short restoration times are met due to the sheer volume of LSPs that have to be re-signaled or redialed when links go down.
Scalability
The current DS-TE solution requires a single class of traffic per LSP. Because many users will have several classes of traffic, this will cause the number of LSPs in the network to increase by a factor of at least two and in some cases, three, four or larger. The number of LSPs is a scalability concern for a number of reasons. Firstly, it is of concern in the forwarding path of the data plane. Since the data plane maintains tables with an entry for each LSP, a larger number of LSPs will mean larger LSP switching tables in the data plane. These tables typically have limits associated with them, which is especially true for high performance hardware based LSP switching. As the number of LSPs increases beyond a certain point, it will be necessary to have caching schemes to retrieve stale LSP entries from the control plane. This causes the packet delay within the device to increase. Secondly, it increases the time required for LSPs to recover in “hitless restart” situations. Finally, it is of concern for the state management of MPLS signaling protocols. For example, distributed RSVP implementations typically maintain four distinct state machines related to the PATH and RESV state blocks (PSB and RSB), as described in ietf draft RFC 2209. Each of these state machines has a list of LSPs associated information stored per LSP. Thus, the signaling time for an RSVP packet is heavily dependent on four different lookups that are performed per node. Reducing the number of LSPs will assist in reducing the LSP setup time and thus, increase the connection setup rate that a node can support.
Network Operations
Another important area of consideration is related to the area of network maintenance and administration. When trouble-shooting issues related to a customer's traffic, the current DS-TE solution frequently requires the network operator to examine multiple LSPs, carrying the different classes of traffic for the same customer.
In summary, a shortcoming of current MPLS packet networks is the limitation that connections can only be set up for one class of service. If a connection for several classes of traffic is required (between the same two end points), the choice is either to set up separate connections, one per class, or to set up a single-class connection with parameters reflecting a compromise of the several classes of traffic that will use this connections. These approaches have numerous drawbacks as has been discussed above.